home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-07-15 | 47.0 KB | 1,491 lines |
- The drawings contained in this Recommendation have been done in Autocad
- Recommendation X.29
- PROCEDURES FOR THE EXCHANGE OF CONTROL INFORMATION
- AND USER DATA BETWEEN A PACKET
- ASSEMBLY/DISASSEMBLY (PAD) FACILITY
- AND A PACKET MODE DTE OR ANOTHER PAD
- (provisional, Geneva, 1977; amended, Geneva, 1980,
- Malaga-Torremolinos, 1984 and Melbourne, 1988)
- Preface
- The establishment in various countries of public data networks providing
- packet-switched data transmission services creates a need to produce standards to
- facilitate international interworking.
- The CCITT,
- considering
- (a) that Recommendations X.1 and X.2 define the user classes of service and
- facilities in a public data network, and Recommendation X.96 defines call
- progress signals;
- (b) that Recommendation X.3 defines the PAD in a public data network;
- (c) that Recommendation X.28 defines the DTE/DCE interface for a start-stop
- mode DTE accessing the PAD in a public data network;
- (d) that Recommendation X.25 defines the interface between the DTE and the
- DCE for DTEs operating in the packet mode in public data networks;
- (e) the need to allow interworking between a packet mode DTE and a
- non-packet mode DTE in the packet-switched transmission service;
- (f) the urgent need to allow interworking between a start-stop mode DTE in
- a public switched telephone network, public switched data network or a leased
- line and a packet mode DTE using the virtual call facility of the packet-switched
- transmission service;
- (g) the need to allow interworking between PADs;
- (h) that the packet mode DTE shall not be obliged to use the control
- procedures for PAD functions, but that some packet mode DTEs may wish to control
- specific functions of the PAD,
- unanimously recommends that
- (1) the Recommendation X.29 procedures shall apply to the Recommendation
- X.25 interface between the DCE and the packet mode DTE;
- (2) the Recommendation X.29 procedures may be applied for interworking
- between PADs;
- (3) the procedures be as specified below in S 1 Procedures for the exchange
- of PAD control information and user data;
- (4) the manner in which user data is transferred be as specified below in S
- 2 User data transfer;
- (5) the procedures for the control of the PAD via PAD messages be as
- specified below in S 3 Procedures for the use of PAD messages;
- (6) the formats of the data fields which are transferable on a virtual call
- be as specified below in S 4 Formats.
- i
- is considered within a national network these packet types or procedures may have
- a different form from those used in Recommendation X.25 but will have the same
- operational meaning.
- Note 2 V The following items are for further study:
- V the use of the permanent virtual circuit service;
- V interworking between DTEs having interfaces to different data
- transmission services;
- V operation of nonVpacket mode DTEs in other than startVstop mode.
- 1 Procedures for the exchange of PAD control information and
- user data
- 1.1 The exchange of control information and user data between a PAD and a
- packet mode DTE or between PADs is performed by using user data fields defined in
- Recommendation X.25.
- 1.2 Annex A describes some of the characteristics of virtual calls as defined
- in Recommendation X.25, as related to the PAD representation of a startVstop mode
- DTE to a packet mode DTE. The characteristics described in Annex A also apply for
- interworking between PADs.
- 1.3 Call user data
- The call user data field call user data field of incoming call or
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- call request packets to or from the packet mode DTE or the PAD is
- comprised of two fields:
- a) the protocol identifier field protocol identifier field, and
- b) the call data field call data field.
- The protocol identifier field is used for protocol identification purposes
- and the call data field contains user data.
- A call request packet received by the PAD, containing no call user data
- field, will be accepted by the PAD.
- If a call data field is present, the PAD will send it, unchanged, to the
- startVstop mode DTE, using the call data block of the incoming call PAD service
- signal (see ' 3.5.22, Recommendation X.28).
- 1.4 User sequences
- 1.4.1 User sequences are used to exchange user data between the PAD and the
- packet mode DTE or a PAD.
- 1.4.2 User sequences are conveyed in the user data fields of complete packet
- sequences with Q = 0, and in both directions on a virtual call. (See
- Recommendation X.25.)
- 1.4.3 There will be only one user sequence in a complete packet sequence.
- 1.4.4 The PAD will transmit all data packets with the D bit set to 0.
- On reception of a data packet with the D bit set to 1, the PAD will
- transmit the corresponding acknowledgement as soon as possible.
- virt
- virtual call.
- As no error correction procedure is in place from the PAD to the
- start-stop mode DTE, no guarantee of delivery can be implied from the
- acknowledgement.
- 1.5 PAD messages
- 1.5.1 PAD messages are used to exchange control information between the PAD and
- the packet mode DTE (or remote PAD). A PAD message consists of a control
- identifier field and a message code field possibly followed by a parameter field (see
- S 4.4 below).
- 1.5.2 PAD messages are conveyed in the user data fields of complete
- packet sequences with Q = 1 and in both directions on a virtual
- call. (See Recommendation X.25.)
- 1.5.3 There will be only one PAD message in a complete packet
- sequence.
- 1.5.4 The PAD will take into consideration a PAD message only when
- it has been completely received.
- 1.5.5 In the case where a parameter reference (see S 3 below)
- appears more than once in a PAD message, only the last appearance
- is taken into account.
- 1.5.6 The PAD will transmit all data packets with the D bit set to
- 0.
- On reception of a data packet with both the Q bit and the D
- bit set to 1, the PAD will transmit the corresponding
- acknowledgement as soon as possible.
- If the PAD does not support the D bit procedure, the PAD may
- reset the virtual call.
- 2 User data transfer
- 2.1 Data packets will be forwarded by the PAD when a set, read, or set and
- read PAD message is received, or under any of the other data forwarding
- conditions provided by the PAD (see Recommendation X.28, S 4.4).
- 2.2 The occurrence of a data forwarding condition will not cause the PAD to
- transmit empty data packets.
- 3 Procedures for the use of PAD messages
- 3.1 Procedures for reading, setting, and reading and setting of PAD parameters
- 3.1.1 The current values of PAD parameters may be changed and read by
- transmitting to the PAD a set, read, or set and read PAD message.
- me
- message as a data forwarding condition.
- 3.1.3 The PAD will respond to a valid read or set and read PAD message by
- transmitting a parameter indication PAD message. This PAD message will have a
- parameter field containing a list of parameter references and current values
- (after any necessary modification) of the PAD parameters to which the received
- PAD message referred.
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- 3.1.4 The PAD will not return a parameter indication PAD message in response to
- a valid set PAD message received.
- 3.1.5 Table 1/X.29 specifies the PAD's response of the PAD to set, set and read,
- and read PAD messages.
- 3.1.6 If the function of a character is duplicated by the selection of parameter
- values by use of the set or set and read PAD message, the PAD will consider these
- parameter changes as valid, and will respond as described in this Recommendation.
- After these changes are invoked, the PAD will follow the procedure described in
- Recommendation X.28, ' 3.3.2.
- 3.2 Procedures for inviting the PAD to clear
- 3.2.1 The invitation to clear PAD message is used to request that
- the PAD clears the virtual call, after transmission of all data
- previously transmitted to the startVstop mode DTE.
- Note V The clear indication packet, which is transmitted by
- the PAD after delivery of the last character to the startVstop mode
- DTE, will have a clearing cause field set to DTE clearing.
- 3.3 Interrupt and discard procedures
- 3.3.1 If parameter 7 is set to 21, the PAD will transmit an interrupt packet
- with all bits of the interrupt user data field set to 0 followed by an indication
- of break PAD message to indicate that the PAD, at the request of the startVstop
- mode DTE, is discarding the user sequences received. The PAD message will contain
- an indication in its parameter field that parameter 8 has been set to 1 (discard
- output).
- 3.3.2 Before resuming data transmission to the PAD, the response to the
- indication of break PAD message shall be a set or set and read PAD
- message, indicating that parameter 8 should be set to 0 (normal
- data delivery).
- Prior to sending this PAD message, any inVprogress complete
- packet sequence being transmitted to the PAD must be terminated
- (with a packet that will be discarded by the PAD) in accordance
- with Recommendation X.25 procedures.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- TABLE 1/X.29
- PAD messages transmitted by the PAD in response to set, set and read, and read PAD
- messages
-
- PAD message received by Corresponding parameter
- the PAD Action upon PAD indication PAD message
- parameters transmitted to the
- Type Parameter packet mode DTE
- field
- None Reset all implemented None
- Recommendation X.3
- parameters to their
- Set initial values
- corresponding to the
- initial profile
- List of Set the selected a) None
- selected parameters to the given b) List of these invalid
- parameters values: parameters
- with the a)if no error is (see Note)
- desired encountered
- values b)if the PAD fails to
- modify the values of some
- parameters
- None Reset all implemented List all implemented
- Recommendation X.3 Recommendation X.3
- Set and parameters to their parameters, and their
- read initial values initial values
- corresponding to the
- initial profile
- List of Set the selected List of these parameters
- selected parameters to the given with their new current
- parameters values values (see Note)
- with the
- desired
- values
- None None List all implemented
- Recommendation X.3
- Read parameters with their
- current values
- List of None List of these parameters
- selected with their current values
- parameters (see Note)
- Note - If any of the parameters contain an error, then the error bit is set and
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- the value field is coded as described in Table 3/X.29.
- 3.3.3 If a PAD receives an indication of break PAD message which contains a
- parameter field as described in S 3.3.1 above, it will respond by transmitting a
- set PAD message as described in S 3.3.2 above and will transmit a break signal to
- the start-stop mode DTE. If a PAD receives an indication of break PAD message
- which does not contain a parameter field, it will not respond to the packet mode
- DTE or PAD but it will transmit a break signal to the start-stop mode DTE.
- 3.3.4 When the PAD transmits an interrupt packet after the receipt from the
- start-stop mode DTE of an interrupt PAD command signal or a break signal, when
- parameter 7 is set to 1, the interrupt user data field is coded in bits 8 to 1 as
- 00000001.
- 3.3.5 If the PAD receives an interrupt packet it will confirm it in accordance
- with Recommendation X.25 procedures. The PAD will not transmit the contents of
- the interrupt user data field to the start-stop DTE. The PAD will ignore the
- values of the interrupt user data field. It is for further study whether the
- coding of this field given in S 3.3.4 above causes a different response.
- 3.3.6 If parameter 7 is set to 5, the PAD will transmit an interrupt packet with
- all bits of the interrupt packet set to 0, followed by an indication of break PAD
- message. The PAD message will not contain a parameter field as described in S
- 4.4.7.
- 3.3.7 Some PADs may always send the break signal to the start-stop mode DTE upon
- receipt of an interrupt packet rather than upon receipt of an indication of break
- PAD message.
- 3.4 Procedure for resets
- Virtual calls may be reset according to the procedures defined in
- Recommendation X.25. The effect of the resetting procedure on the value of PAD
- parameter 8 is to reset its value to 0 (normal data delivery). The current values
- of all other PAD parameters are not affected.
- 3.5 Error handling procedures by the PAD
- 3.5.1 If the PAD receives a set, read or set and read PAD message containing an
- invalid reference to a PAD parameter, the parameter field within the parameter
- indication PAD message transmitted by the PAD will contain an indication that
- this has occurred. The remaining valid references to PAD parameters are processed
- by the PAD.
- Possible reasons for an invalid access to a PAD parameter are:
- a) the parameter reference has not been implemented in the PAD;
- b) the parameter value has not been implemented in the PAD or cannot be
- altered from the current setting;
- c) the parameter is a read-only one (set and set and read PAD messages
- only);
- d) the parameter follows an invalid parameter separator (see S 4.4.5.4
- below).
- 3.5.2 The PAD will transmit an error PAD message containing the message code of
- an invalid PAD message received under the following conditions:
- a) if the PAD receives an unrecognizable message code;
- b) if the parameter field following a recognizable message code is
- incorrect or incompatible with the message code;
- c) if the parameter field following a recognizable message code has an
- invalid format;
- d) if the PAD receives an unsolicited parameter indication PAD message;
- e) if the PAD receives a PAD message that is too long.
- 3.5.3 The PAD will transmit an error PAD messag D message
- containing less than 8 bits is received.
- 3.5.4 If the PAD receives an error PAD message it will not respond
- with a PAD message of any type. Subsequent action is for further
- study.
- 3.6 Procedures for inviting the PAD to reselect the called DTE
- The reselection or reselection with TOA/NPI PAD message (Type of
- address/Numbering Plan Indicator) used by a packet mode DTE to request that the
- PAD clear the virtual call, after transmission to the start-stop mode DTE of all
- the previously transmitted data. Then, the PAD will establish a call to the
- reselected DTE.
- Note - The TAO/NPI address subscription facility is designated in
- Recommendation X.2 for further study.
- When the reselection PAD message is received, the PAD will transmit an
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- error PAD message with an error type unauthorized reselection PAD message
- (00000110) under the following conditions:
- a) the virtual call has been established by the packet-mode DTE;
- b) the called DTE reselection prevention facility has been requested by
- the start-stop mode DTE;
- c) the reselection PAD message has been already received more than N times
- (where N is for further study).
- The format of the reselection PAD message is given in S 4.4.9 below. The
- format of the reselection with TOA/NPI PAD message is given in S 4.4.10 below.
- These messages contain the information needed by the PAD to establish the new
- virtual call.
- Upon receipt of the reselection or reselection with TOA/NPI PAD message,
- the PAD will:
- - transmit to the start-stop mode DTE all previously received data;
- - clear the virtual call that is established;
- - after having made the appropriate state changes as described in
- Recommendation X.28, S 3.2.5, establish a virtual call to the
- reselected DTE. The call request packet sent by the PAD, will contain
- only the facilities subscribed by the start-stop mode DTE and/or
- assigned by default. Any other facilities contained in the reselection
- PAD message will be ignored. In particular:
- i) Closed User Group Signals - Independently by the CUG indicated in
- the reselection PAD message, the PAD will use the same CUG of the
- original call.
- message
- message contains the reverse charging facility.
- iii) Charging information:
- V facility assigned for an agreed contractual period: The
- information will be sent to the startVstop mode DTE at the
- clearing of each call (original and reselected), or at the
- clearing of the last reselected call. If the later procedure was
- selected, the PAD will send the total charging information,
- without sending the charge of the individual calls (original and
- reselected).
- V facility on a per call basis: The PAD follows the procedure
- indicated above, starting from the first charging information
- facility request (by the startVstop mode DTE or packet mode
- DTE).
- iv) RPOA selection: for further study
- Note V The other facilities indicated in Table 4/X.28 with Note 2 are for
- further study.
- Note V This procedure is an optional feature of the PAD. PADs which do not
- implement this feature will consider reselection and reselection with TOA/NPI PAD
- messages as invalid. PADs may implement this feature either by accepting (1)
- reselection PAD messages or (2) reselection and reselection with TOA/NPI PAD
- messages. The sending of reselection or reselection with TOA/NPI PAD messages by
- a PAD is for further study.
- 4 Formats
- 4.1 Introduction
- Bits of octets are numbered 8 to 1 where bit 1 is the low order bit and is
- transmitted first. Octets of the call user data, of user sequences, of PAD
- messages and of interrupt user data are consecutively numbered starting from 1
- and are transmitted in this order.
- 4.2 Call user data format (see Figure 1/X.29)
- 4.2.1 Protocol identifier format
- The protocol identifier field protocol identifier field standardized by
- CCITT consists of four octets.
- The first octet is coded as follows:
- bits 8 and 7 = 00 for CCITT use
- = 01 for national use
- = 10 reserved for international user bodies
- = 11 for DTEVDTE use.
- C
- CCITT, subject to the rules of Recommendation X.244. All bits of
- octets 2, 3 and 4 are set to 0. These octets are reserved as a
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- future mechanism for providing the called PAD or packet mode DTE
- with additional information pertinent to the calling party.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- Fig. 1/X.29 = 6 cm
-
- 4.2.2 Call data format
- Octets of the a field will contain the user
- characters received by the PAD from the start-stop mode DTE during
- the call establishment phase. The coding of these octets is similar
- to that of user sequences (see S 4.3 below). The call data field is
- limited to 12 octets (see Figure 1/X.29).
- 4.3 User sequence format
- 4.3.1 The order of bit transmission from the PAD is the same as the order that
- bits are received from the start-stop mode DTE. The order of bit transmission to
- the start-stop mode DTE is the same as the order that bits are received.
- 4.3.2 No maximum is specified for the length of a user sequence.
- 4.4 Control message format
- 4.4.1 Bits 8, 7, 6, 5 of octet 1 of a user data field of complete packet
- sequences with Q = 1 are defined as the control identifier field, used to
- identify the facility, such as PAD, to be controlled. The control identifier
- fiel coding for PAD messages to control a PAD
- for a start-stop mode DTE is 0000. Other codings of the control
- identifier field are reserved for future standardization.
- Note - The possibility of extending the control identifier
- field is for further study.
- 4.4.2 When the control identifier field (see S 4.4.1 above) is set
- to 0000, bits 4, 3, 2, 1 of octet 1 are defined as the message code
- field. The message code field is used to identify
- specific types of PAD messages, as given in Table 2/X.29.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- TABLE 2/X.29
- Type and coding of octet 1 of PAD messages
-
- Message code
- Type Bit 4 3 2 1
- s
- Set PAD message 0 0 1 0
- Read PAD message 0 1 0 0
- Set and read PAD message 0 1 1 0
- Parameter indication PAD message 0 0 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- 0
- Invitation to clear PAD message 0 0 0 1
- Indication of break PAD message 0 0 1 1
- Reselection PAD message 0 1 1 1
- Error PAD message 0 1 0 1
- Reselection with TOA/NPI 1 0 0 0
- Note - The possibility of extending the message code field is for further study.
- 4.4.3 All PAD messages consist of a control identifier field (bits 8, 7, 6, 5 of
- octet 1 equal to 0000) and a message code field (bits 4, 3, 2, 1 of octet 1).
- Set, read, set and read and parameter indication PAD messages consist of
- octet 1 which may be followed by one or more parameter fields. Each parameter
- field c a parameter reference octet and a
- parameter value octet.
- The parameter value octets of the read PAD message contain the
- value 0.
- The error PAD message consists of octet 1 and one or two
- octets giving the reason for the error.
- The indication of break PAD message consists of octet 1 which
- may be followed by a parameter field.
- The invitation to clear PAD message consists of octet 1 only.
- 4.4.4 The maximum length of PAD message is network dependent, but
- will be at least 128 octets.
- 4.4.5 Parameter field for set, read, set and rea , and parameter
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- indication PAD messages (see Figure 2/X.29)
- A parameter field contained in one of these PAD messages consists of a
- reference f d and a value field. A parameter
- field is two octets in length, except when the extension mechanism
- is used (see S 4.4.5.1 below).
- c
- coded in bits 7 to 1, where bit 1 is the low order bit. Reference
- fields need not be ordered by increasing parameter reference
- numbers.
- The code 1111111 (decimal 127) in bits 7 to 1 of the reference
- field will be used for the extension of this field. Such coding
- will indicate that there is another octet following. The following
- octet is coded with the parameter reference of Recommendation X.3
- minus 127.
- 4.4.5.2 In PAD messages received by the PAD, bit 8 of each octet
- will be ignored. In parameter indication PAD messages, bit 8 of
- each reference field set to 1 will indicate an invalid access to
- the referred parameter as described in S 3.5 above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- Fig. 2/X.29 = 13 cm
-
- 4.4.5.3 A parameter value field consists of a value of the parameter reference,
- identified as a decimal number in Recommendation X.3, and is binary coded in bits
- 8 to 1, where bit 1 is the low order bit. Value fields in read PAD messages are
- coded as all binary 0s. In set and set and read PAD messages, they will indicate
- the requested values of parameters. In parameter indication PAD messages, they
- will indicate the current values of PAD parameters, after modification if any. If
- bit 8 (error bit) is set to 1 in the preceding octet (i.e. the parameter
- reference field), the parameter value field will indicate the reason for the
- error, as given in Table 3/X.29.
- 4.4.5.4 Parameters not standardized by CCITT may be supported. The parameter
- separator is used in PAD messages to indicate the separation between parameters
- specified in Recommendation X.3 and any others implemented nationally or locally.
- The parameter separator consists of a parameter field which contains a
- reference field set to 00000000 and a value field set to 00000000.
- When present, the parameter separator and the national or local parameter
- fields must be placed after any CCITT standardized parameter fields in PAD
- messages.
- Note - It is recommended that only the parameters defined in
- Recommendation X.3 are used when communicating with a PAD in a different country
- or network.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- TABLE 3/X.29
- Coding of parameter value field in case of error
-
- Parameter value field code
- Error type bits Decimal
- 8 7 6 5 4 3 2 1
- No additional information 0 0 0 0 0 0 0 0 0
- The parameter reference does not exist or 0 0 0 0 0
- has not been implemented in the PAD
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- 0 0 1 1
- The parameter value is invalid or has not 0 0 0 0 0 0 1 0 2
- been implemented in the PAD
- The parameter value cannot be altered from 0 0 0 0 0 0 1 1 3
- the current setting
- The parameter is read-only 0 0 0 0 0 1 0 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- 4
- The parameter follows an invalid parameter 0 0 0 0 0 1 0 1 5
- separator
- Note - The value 0 is mandatory. Other values are optional.
- 4.4.6 Format of error PAD messages (see Figure 3/X.29)
- Fig. 3/X.29 = 7 cm
-
- 4.4.6.1 Octet 2 of the error PAD message will be coded as shown in Table
- 4/X.29.
- 4.4.6.2 In cases b, c, d, e and f in Table 4/X.29, octet 3 of an error PAD
- message will contain the message code of the received PAD message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- 4.4.7 Parameter field for indication of break PAD messages (see Figure 4/X.29)
- This PAD message may either not contain a parameter field, or contain a
- parameter field consisting of 2 octets (i.e. one reference field and one value
- field) coded as follows: the reference field will be coded 00001000 (indicating
- parameter 8) and the value field will be coded 00000001 (indicating decimal 1).
- TABLE 4/X.29
- Coding and meaning of octet 2 of error PAD messages
-
- Coding
- Case Meaning Bits 8 7 6 5 4 3 2 1
- a Received PAD message contained 0 0 0 0 0 0 0 0
- less than eight bits
- b Unrecognized message code in
- received PAD message
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- 0 0 0 0 0 0 1 0
- c Parameter field format of 0 0 0 0 0 1 0 0
- received PAD message was
- incorrect or incompatible with
- message code
- d Received PAD message did not 0 0 0 0 0 1 1 0
- contain an integral number of
- octets
- e Received parameter indication
- PAD message was unsolicited
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- 0 0 0 0 1 0 0 0
- f Received PAD message was too 0 0 0 0 1 0 1 0
- long
- g Unauthorized reselection PAD 0 0 0 0 1 1 0 0
- message
- Fig. 4/X. 29 = 5 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- 4.4.8 Parameter field for invitation to clear PAD message (see Figure 5/X.29)
- Fig. 5/X.29 = 5 cm
-
- This PAD message will not contain a parameter field.
- 4.4.9 Reselection PAD message format
- The format of this message is given in Figure 6/X.29.
- Fig. 6/X.29 = 9 cm
-
- 4.4.9.1 Reselected DTE address length field
- Bits 4, 3, 2 and 1 of the reselected DTE address length field indicate the
- length of the reselected DTE address in semi-octets. The address length is binary
- coded and bit 1 is the low order bit of the indicator.
- 4.4.9.2 Address field
- Octet 3 and the following octets consist of the reselected DTE address.
- Each digit of the address is coded in a semi-octet in binary coded decimal with
- bit 5 or 1 being the low order bit of the digit.
- Starting from the high order digit, the address is coded in octet 3 and
- consecutive octets with two digits per octet. In each octet, the higher order
- digit is coded in bits 8, 7, 6 and 5.
- The address field shall be rounded up to an integral number of octets by
- inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when
- necessary.
- The reselected DTE address field should contain the internat
- number (DNIC + Network terminal number).
- 4.4.9.3 Facility length field
- The octet following the reselected DTE address field indicates the length
- of the facility field, in octets. The facility length indicator is binary coded
- and bit 1 is the low order bit of the indicator.
- 4.4.9.4 Facility field
- The facility field is present only when optional user facilities are
- included by the DTE. This field indicates the facilities that must be included in
- the facility field of the incoming call packet received by the reselected DTE
- (see S 3.6).
- The coding of the facility field is defined in S 7 of Recommendation X.25.
- The facility field contains an integral number of octets, the maximum
- length of the complete PAD message is restricted, as described in S 4.4.4 above.
- 4.4.9.5 Call user data field
- Following the facility field, the call user data field may be present and
- has a maximum length of 12 octets.
- Call user data when present in the call user data field of the reselection
- PAD message is included in the call user data field of the incoming call packet
- received by the reselected DTE.
- 4.4.10 Reselection with TOA/NPI PAD message format
- The format of this message is given in Figure 7/X.29.
- Note - The TOA/NPI address subscription facility is designated in
- Recommendation X.2 for further study.
- Fig. 7/X.29 = 8 cm
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
- 4.4.10.1 Reselected DTE address length field
- Octet 2 indicates the length of the reselected DTE address in semi-octets.
- The address length is binary coded and bit 1 is the low order bit of the
- indicator. The maximum value of the reselected DTE address length field is 17.
- 4.4.10.2 Reselected DTE address field
- Octet 3 will consist of the TOA/NPI indication as described in
- Recommendation X.25. The following octets consist of the reselected DTE address.
- Each digit of the address is coded in a semi-octet in binary coded decimal with
- bit 5 or 1 being the low order bit of the digit. Starting from the high order
- digit, the address digits are coded in consecutive semi-octets. In each octet,
- the higher order digit is coded in bits 8, 7, 6 and 5.
- 4.4.10.3 Facility length field
- The octet following the address field indicates the length of the facility
- field, in octets. The facility length indicator is binary coded and bit 1 is the
- low order bit of the indicator.
- 4.4.10.4 Facility field
- (See S 4.4.9.4.)
- 4.4.10.5 Call user data field
- (See S 4.4.9.5.)
- ANNEX A
- (to Recommendation X.29)
- Characteristics of virtual calls and Recommendation X.25
- as related to the PAD representation of
- a start-stop mode DTE to a packet mode DTE
- A.1 General interface characteristics
- A.1.1 The mechanical, electrical, functional and procedural characteristics to
- activate, maintain and deactivate the physical access path between the DTE and
- the DCE will be in accordance with the physical level procedures of
- Recommendation X.25.
- A.1.2 The link access procedure for data interchange across the link between the
- DTE and DCE will be in accordance with the link level procedures of
- Recommendation X.25.
- A.1.3 The packet format and control procedures for the exchange of packets
- containing control information and user data between the DTE and the DCE will be
- in accordance with the packet level procedures of Recommenda-tion X.25.
- A.2 Interface procedures for virtual call control
- A.2.1 Incoming calls are indicated to the packet mode DTE as specified in
- Recommendation X.25. Call requests are indicated by the packet mode DTE as
- specified in Recommendation X.25. Any use of optional user facilities are
- indicated in accordance with SS 6 and 7 of Recommendation X.25.
- A.2.2 The default throughput classes used by the PAD are determined by the data
- rates of the start-stop mode DTE (where exact correspondence is not obtained, the
- next higher throughput class is used).
- A.2.3 The PAD and the packet mode DTE will use the clearing procedures specified
- in SS 4.1.7, 4.1.8 and 4.1.9 of Recommendation X.25.
- A.3 Interface procedures for data transfer
- A.3.1 Data transfer on a virtual call can only take place in the data transfer
- state and when flow control permits (see S 4.4 of Recommendation X.25). The same
- is true for the transfer of interrupt packets (see S 4.3 of Recommendation X.25).
- A.3.2 Interrupt packets transmitted by the packet mode DTE will be confirmed by
- the PAD following the procedures in Recommendation X.25.
- A.3.3 The reset procedure may be used by the packet mode DTE or the PAD to
- re-initialize the virtual call and will conform to the procedures described in S
- 4.4.3 of Recommendation X.25.
- A.3.4 A reset of the virtual call originated by the packet mode DTE or due to
- network congestion may be indicated by the PAD to the start-stop mode DTE.
- A.3.5 A reset procedure initiated by the PAD may be due either to:
- a) the receipt at the PAD of a request to reset from the non-packet mode
- DTE. The resetting cause contained in the reset indication packet will
- be DTE reset; or
- b) a PAD or network failure.
- A.3.6 For calls received by the PAD with bit 7 of octet 1 in the incoming call
- packet set to 0, the PAD will set bit 7 of octet 1 in the call accepted packet to
- 0 and will set the D bit in transmitted data packets to 0.
- Pending further study, and in the absence of bilateral agreement between
-
-
-
-
- PAGE14 Fascicle VIII.2 - Rec. X.29
-
- Administrations (used in conjunction with the D bit modification facility), the
- following applies:
- If the incoming call packet received by the PAD has bit 7 of octet 1 set
- to 1, the PAD may set bit 7 of octet 1 of the call accepted packet to 1.
- Calls originated by the PAD will set bit 7 of octet 1 in call request
- packets to 0. The called DTE can indicate if it requires the support of the D bit
- procedure by setting bit 7 of octet 1 of call accepted packets to 1.
- PAD procedures associated with the Delivery Confirmation (D) bit in data
- packets (see S 4.3.3 of Recommendation X.25) are described in SS 1.4.4 and 1.5.6.
- A.4 Virtual call characteristics
- A.4.1 Resetting
- A.4.1.1 There may be a loss of data characters in any case of reset, as stated
- in Recommendation X.25. Characters generated by either of the DTEs prior to the
- reset indication or confirmation will not be delivered to the other DTE after the
- reset indication or confirmation.
- A.4.2 Interrupt transfer
- A.4.2.1 An interrupt packet is always delivered at or before the point in the
- data packet stream at which it was generated.
- A.4.3 Call clearing
- Data packets transmitted immediately before a clear request packet is
- sent, may be overtaken within the network by the clear request packet and
- subsequently be destroyed, as described in S 4.5 of Recommendation X.25.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Fascicle VIII.2 - Rec. X.29 PAGE1
-
-